libhv defaults to its `file_logger` which writes to `bin/libhv.YYYYMMDD.log`.
That file is invisible under `popen`/CI runners — when something inside the
HTTP server hangs or fails to bind, there's no way to see what libhv is
trying to do.

This commit reads `DASLIVE_HV_LOG` at `Module_HV` construction and routes
libhv accordingly:

  DASLIVE_HV_LOG=stderr (or =1)  -> hlog_set_handler(stderr_logger)
  DASLIVE_HV_LOG=stdout           -> hlog_set_handler(stdout_logger)
  DASLIVE_HV_LOG=silent           -> hlog_disable()

`DASLIVE_HV_LOG_LEVEL=DEBUG/INFO/WARN/ERROR` separately overrides the level
(default INFO).

Default unset preserves the existing file-logger behavior — no change for
non-CI users.

Smoke (Windows, `--headless`):

  set DASLIVE_HV_LOG=stderr
  set DASLIVE_HV_LOG_LEVEL=DEBUG
  daslang-live foo.das -- --headless
  -> stderr: "INFO http server listening on 0.0.0.0:9090 [HttpServer.cpp:184:http_server_run]"
              "DEBUG hloop_new tid=4572 [hloop.c:431:hloop_new]"
              "INFO  EventLoop started, pid=99632 tid=4572 [HttpServer.cpp:151:loop_thread]"
              "DEBUG hloop_run tid=4572 [hloop.c:454:hloop_run]"

Motivation: dasImgui CI hangs on both Linux and macOS in dasHV's HTTP
serving (script's update loop iterates, but /status never responds). Need
visibility into libhv's event loop state to diagnose — file_logger is
unreachable from the popen'd subprocess on the runner.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…yling

site/blog: RSS link polish, feed author, landing auto-discovery

…oute-env

dasHV: env-gated libhv log routing (stderr / stdout / silent)

Until this commit, ref_time_ticks() returned raw QueryPerformanceCounter
ticks on Windows (~10 MHz) and clock_gettime nanoseconds on Linux/macOS.
Any caller that did raw arithmetic on the result -- the natural

    let deadline = ref_time_ticks() + int64(timeout_sec * 1_000_000)
    while (ref_time_ticks() < deadline) { ... }

deadline pattern -- silently got 30 s on Windows (lucky math at 10 MHz)
and 30 ms on POSIX (1000x too short). Recently surfaced as a CI hang in
dasImgui's playwright harness, which read deadlines that elapsed instantly
on Linux/macOS runners.

Normalize ref_time_ticks() to nanoseconds on Windows by dividing the QPC
counter by the cached QueryPerformanceFrequency. The conversion uses a
split whole+remainder fold so the intermediate never overflows int64.
QPF is cached once per process (invariant after boot, race-tolerant).

Helpers (get_time_usec, get_time_nsec, ref_time_delta_to_usec) become
trivial subtraction/division now that the unit is uniform; the Windows
ref_time_delta_to_usec also loses a long-standing QPC-for-QPF typo that
made it return garbage in the old implementation. The POSIX helpers are
unchanged in semantics, just tidied for symmetry.

All in-tree callers (C++ and .das, including dastest, daslib/profiler,
strudel, examples, MCP tools) already use the safe `let t0 = ref_time_ticks()`
+ `get_time_usec(t0)` pattern, so no caller changes are needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous commit's split conversion (whole+rem with two idiv per call)
doubled the cost of ref_time_ticks() from ~22 ns to ~40 ns on modern
Windows. That matters for the function profiler, which brackets every
profiled call: ~36 ns of profiler skew per function vs ~14 ns before.

Precompute `qpc_ns_per_tick = 1e9 / freq` once when QPF divides 1e9
cleanly. On every Win 7+ box that's the case (QPF is fixed at 10 MHz,
ns_per_tick = 100), so the hot path collapses to one multiply and the
call returns to ~23 ns -- within 1 ns of the bare QueryPerformanceCounter
cost.

The split fallback stays for paranoid completeness on non-divisible QPF
(theoretical; not observed on shipping Windows hardware in years).

Microbench on this box (QPF=10MHz, MSVC /O2, 50M iterations):

  ref_old      (raw QPC, returns ticks)       22.3 ns/call    1.00x
  ref_new_split (whole+rem -> ns, previous)   39.8 ns/call    1.79x
  ref_new_fast  (ticks * ns_per_tick)         23.0 ns/call    1.03x

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Update the handmade RST blurb for builtin::ref_time_ticks to reflect the
new contract: monotonic timestamp in nanoseconds, raw subtraction valid
since the unit is uniform across Windows/Linux/macOS. The previous wording
described the return value as opaque "ticks", which was platform-dependent
and led to caller-side deadline-math bugs (the dasImgui CI hang).

Sphinx clean build succeeded, zero new warnings.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…cks-normalize-ns

ref_time_ticks: normalize to nanoseconds on every platform